The viewer experience with delivery of digital video content via broadcast channels is often poor. Because of the characteristics of compressed video encoding, the viewer often waits seconds after selection of a broadcast channel until the digital video content is finally displayed. Because viewers are accustomed to near instantaneous channel change functionality with analog television, the quality of the digital television experience often times does not meet viewer expectations.
One cause of the slow channel change problem involves the framing of compressed video (e.g., MPEG2 or MPEG4/H.264). In order to minimize bandwidth, the majority of the frames contained within a compressed stream of digital video content are P-frames and B-frames, which are frames that encode changes to a displayed image. An I-frame (MPEG2) on the other hand is a frame that presents a complete new image. The rate at which I-frames (or equivalent I-slice constructs in MPEG4) are delivered in a digital video stream is typically one I-frame every ¼ to 2 seconds, depending on the amount of motion contained within the stream. The delay after requesting a channel change is dominated by having to wait until the next I-frame finally arrives, which can be up to 2 seconds, before the new channel can be displayed.
In an Internet Protocol (IP) television environment, different channels of digital video content are distributed to multiple clients via IP multicasting. One technique for implementing a fast channel change in an IP television environment is described in U.S. Pat. Publ. No. 2005/0081244 to Barret et al. The technique described by Barret et al. involves servicing a channel change request by 1) retaining an I-frame from each different broadcast stream, and then 2) transmitting the retained I-frame for the requested channel to the corresponding client via a unicast message instead of via a multicast message. The I-frame is then used to quickly display the requested channel. Once the retained I-frame is sent to the client via the unicast message, the client is rapidly joined to the multicast group corresponding to the requested channel in time for the client to receive the next I-frame via multicasting. In IP television environments, internet group management protocol (IGMP) is typically used to join clients to multicast groups. While transmitting an I-frame via a unicast message works well to achieve a fast channel change, using IGMP to join a client to a multicast group requires multiple messages between client and server. When a large number of channel change requests are made in a short period of time, the flood of associated IGMP messages can introduce significant delay into the network. In particular, delay associated with the IGMP messages can place limitations on the scalability of this fast channel technique.
In addition to a channel change being fast, it is important to the viewer experience that the quality of the post-channel change content be comparable to the quality of the pre-channel change content. Real-time Transport Protocol (RTP) is a packet-based protocol that is widely used to stream video media. RTP Control Protocol (RTCP) is a control protocol for use with RTP. Upon receiving a new stream of digital video content, typical RTP/RTCP schemes require the receiving client to wait for a client buffer to grow large enough to sustain negative acknowledgements before digital video content from the new stream can be played out at the client. The wait time can be reduced by sending an initial burst of digital video content to the client to rapidly fill the buffer. Although it is possible to transmit a large initial burst of digital video content to rapidly fill a client buffer, this approach does not scale well in a multiclient digital video network.
In view of this, what is needed is a technique for streaming digital video content to a client, including providing fast channel changes, which is able to provide new streams of digital video content to a client with minimal delay at an acceptable quality level and which scales well when applied in a multi-client network.